1. Field of the Invention
This invention relates generally to addressing objects in an object-oriented programming environment.
2. Discussion of the Related Art
Large computer systems permitting many users to simultaneously use single computer resources are herein denominated multitasking computer systems. Such multitasking systems can be interconnected through networks to permit concurrent processing over a distributed plurality of computer resources. The concurrent activities of a large number of simultaneous users are managed by an operating system, which must provide the necessary data structures for tracking and controlling many concurrent processes. Requisite data structures include those needed to manage the distributed memory and the multiple central processing unit (CPU) resources that are used by user processes throughout the network.
If every user process were completely independent, having its own dedicated resources, and there were no concerns about which resources each process must use, operated systems could be relatively simple. However, networked or distributed computer resources are usually shared by many user processes, each requiring access to commonly-owned resources. In fact, each user process may generate a number of simultaneous execution threads that must also share resources among themselves and communicate with the threads and processes of other users.
Modern operating systems employ object architectures to govern data access and transfers among concurrent processes. As used herein, objects include data structures holding information that must be protected from unauthorized access by other user processes. Objects are created by the operating system responsive to user requests and are structured to permit access by the requesting user through system routines that protect the integrity of each object.
The concepts of object identifier and object address (or reference) are well-known in the typical object-oriented programming art. As used herein, an object identifier denominates a value that can be used to uniquely identify an object for the lifetime of that object across some defined domain, such as a single system, a network of systems or the set of all systems in some predefined universe. As used herein, an object address (or reference) denominates a value that allows a user application to conduct high-performance operations on an object in a local virtual address space assigned to the associated user application process. An object address need not be unique in any domain broader than the local virtual address space in which it is used. As known in the art, the concepts of object identifier and object address are separate and distinct.
An object identifier is needed to identify an object having a lifetime that exceeds its local address lifetime. Object identifiers are used, for instance, to manage a network of objects, herein denominating a structure embracing a multiplicity of objects linked together by stored object identifiers each linked to an object within the multiplicity. When an object must be moved from one system to another or from one process to another, for instance, to permit controlled access by many different users, the only consistent means available for tracking such objects is the object identifier, which remains invariant during the interprocess transition from one virtual address space to another.
Because object address and object identifier are conceptually distinct and have independent values, the systems programmer must provide for both. For instance, storage must be allocated for both, storing and updating operations must be allocated for both and so forth. This doubled complexity reduces programming productivity and increases the probability of programming error. There is, accordingly, a clearly-felt need in the art to provide both functions in a single data structure. Although this could be accommodated merely by concatenating the two values into a single double-sized data structure, such a solution offers no reduction in programming complexity because no storage allocation or updating operations are thereby avoided.
Practitioners in the art have proposed a number of solutions to the object-oriented programming complexity problem. For instance, one solution uses a server process that temporarily impersonates the characteristics of a client process when the client process performs a remote procedure call on the server process in a multitasking system. This impersonation is accomplished by creating a new object identifier list that is either the same as the client process list or represents the union of the server and client lists. Such an access control list is provided in each object to define those identifiers required to access the object. Thus, when the identifier list is modified to map all necessary identifiers to local addresses, access checking software in the operating system may then enable the impersonating process to access the specified object. This solution arguably increases programming complexity to accomplish the necessary manipulation of mapping tables that relate object identifiers to local addresses.
Similarly, another solution uses a system for creating "conditional" objects having different object pointers for accessing selected system resources. This object-based operating system supports multiple levels of visibility, thereby permitting objects to be manipulated only by processes within the object's "range" of visibility. An object or an object network can be moved up to a higher visibility level for more object sharing and down to a lower visibility level for more restricted or privileged access. The visibility restriction is achieved by giving each process a pointer (object identifier) to its own process-level container directory and providing for a "public display" container directory permitting interprocess object access. Thus, such a scheme requires a multiplicity of different directories and object identifier mapping tables within each process for linking each global object identifier to various local virtual addresses, increasing rather than reducing programming complexity.
Another approach achieves a virtual look-aside facility for maintaining named data objects in class-related data spaces in virtual storage by providing for an ordered list of "major names" within each user process that is sequentially searched for a specified "minor name" to obtain a virtual storage copy of a data object. This requires a control structure designed to capture information about the location of data within a tree structure that is implicitly created by a naming technique that is commonly used during routine caching operations. This information by-product, selectively used to improve performance in subsequent transactions, does nothing to reduce the programming complexity associated with object naming conventions.
Also known in the art is an object identifier generator for producing unique identifiers in a distributed computer system by concatenating the identifier of the creating node firstly with a creation time from an associated clock adjusted to ensure uniqueness, secondly with a random name-sequence, and finally with a system version number. This generator ensures the creation of an object identifier that is unique across an indefinite universe of computer systems but does not affect the programming complexity problem.
Other related approaches include a system environment that employs workspace name tables for linking packaged workspaces (user processes). An active workspace accesses a loaded copy of the packaged workspaces using the external names of named objects in a packaged workspace rather than the internal names of its own named objects. This system is controlled through a packaged workspace name table stored in the active workspace, which can be merged with other name tables from other packaged workspaces and also shared among a plurality of active workspaces. As with other known object identifier to local address mapping schemes, this system merely maps object identifiers to local addresses and does nothing to reduce programming complexity.
It can be appreciated from the above survey that practitioners in the art, until now, appear to rely on mapping tables with controlled access and duplication privileges to establish and control the relationship between global object identifiers and local virtual addresses, which does nothing to improve programming efficiency. The related unresolved deficiencies are clearly felt in the art and are solved by this invention in the manner described below.